رام کردن هیولا: استراتژی‌های ریفکتورینگ برای کدهای لگسی

کد لگسی (Legacy code). خود این اصطلاح اغلب تصاویری از سیستم‌های گسترده و بدون مستندات، وابستگی‌های شکننده و حسی طاقت‌فرسا از ترس و وحشت را تداعی می‌کند. بسیاری از توسعه‌دهندگان در سراسر جهان با چالش نگهداری و توسعه این سیستم‌ها روبرو هستند که اغلب برای عملیات کسب‌وکار حیاتی هستند. این راهنمای جامع، استراتژی‌های عملی برای ریفکتورینگ کدهای لگسی ارائه می‌دهد و یک منبع ناامیدی را به فرصتی برای نوسازی و بهبود تبدیل می‌کند.

کد لگسی چیست؟

پیش از پرداختن به تکنیک‌های ریفکتورینگ، ضروری است که تعریف کنیم منظور ما از «کد لگسی» چیست. در حالی که این اصطلاح می‌تواند به سادگی به کدهای قدیمی اشاره داشته باشد، یک تعریف دقیق‌تر بر قابلیت نگهداری آن تمرکز دارد. مایکل فدرز (Michael Feathers) در کتاب برجسته خود «کار موثر با کدهای لگسی»، کد لگسی را به عنوان کدی بدون تست تعریف می‌کند. این فقدان تست باعث می‌شود که اصلاح ایمن کد بدون ایجاد رگرسیون (regression) دشوار باشد. با این حال، کد لگسی می‌تواند ویژگی‌های دیگری نیز داشته باشد:

• فقدان مستندات: توسعه‌دهندگان اصلی ممکن است شرکت را ترک کرده باشند و مستندات کمی در مورد معماری سیستم، تصمیمات طراحی یا حتی عملکرد اولیه به جا گذاشته باشند یا اصلاً مستنداتی وجود نداشته باشد.
• وابستگی‌های پیچیده: کد ممکن است به شدت به هم‌پیوسته (tightly coupled) باشد، که این امر جداسازی و اصلاح اجزای منفرد را بدون تأثیر بر سایر بخش‌های سیستم دشوار می‌کند.
• فناوری‌های منسوخ: کد ممکن است با استفاده از زبان‌های برنامه‌نویسی، فریم‌ورک‌ها یا کتابخانه‌های قدیمی نوشته شده باشد که دیگر به طور فعال پشتیبانی نمی‌شوند و خطرات امنیتی ایجاد کرده و دسترسی به ابزارهای مدرن را محدود می‌کنند.
• کیفیت پایین کد: کد ممکن است حاوی کدهای تکراری، متدهای طولانی و دیگر بوهای کد (code smells) باشد که درک و نگهداری آن را دشوار می‌کند.
• طراحی شکننده: تغییرات به ظاهر کوچک می‌توانند عواقب پیش‌بینی‌نشده و گسترده‌ای داشته باشند.

مهم است توجه داشته باشید که کد لگسی ذاتاً بد نیست. این کد اغلب نمایانگر یک سرمایه‌گذاری قابل توجه است و دانش دامنه (domain knowledge) ارزشمندی را در خود جای داده است. هدف از ریفکتورینگ، حفظ این ارزش و در عین حال بهبود قابلیت نگهداری، قابلیت اطمینان و عملکرد کد است.

چرا کدهای لگسی را ریفکتور کنیم؟

ریفکتورینگ کدهای لگسی می‌تواند یک کار دلهره‌آور باشد، اما مزایای آن اغلب بر چالش‌ها غلبه می‌کند. در اینجا برخی از دلایل کلیدی برای سرمایه‌گذاری در ریفکتورینگ آورده شده است:

• بهبود قابلیت نگهداری: ریفکتورینگ باعث می‌شود کد آسان‌تر فهمیده، اصلاح و اشکال‌زدایی شود و هزینه و تلاش مورد نیاز برای نگهداری مداوم را کاهش می‌دهد. برای تیم‌های جهانی، این امر به ویژه مهم است، زیرا وابستگی به افراد خاص را کاهش داده و اشتراک دانش را ترویج می‌دهد.
• کاهش بدهی فنی: بدهی فنی به هزینه ضمنی دوباره‌کاری ناشی از انتخاب یک راه‌حل آسان در حال حاضر به جای استفاده از یک رویکرد بهتر که زمان بیشتری می‌برد، اشاره دارد. ریفکتورینگ به پرداخت این بدهی کمک کرده و سلامت کلی پایگاه کد را بهبود می‌بخشد.
• افزایش قابلیت اطمینان: با پرداختن به بوهای کد و بهبود ساختار کد، ریفکتورینگ می‌تواند خطر بروز باگ‌ها را کاهش داده و قابلیت اطمینان کلی سیستم را بهبود بخشد.
• افزایش عملکرد: ریفکتورینگ می‌تواند گلوگاه‌های عملکرد را شناسایی و برطرف کند و منجر به زمان اجرای سریع‌تر و پاسخ‌دهی بهتر شود.
• یکپارچه‌سازی آسان‌تر: ریفکتورینگ می‌تواند یکپارچه‌سازی سیستم لگسی با سیستم‌ها و فناوری‌های جدید را آسان‌تر کرده و نوآوری و نوسازی را امکان‌پذیر سازد. به عنوان مثال، یک پلتفرم تجارت الکترونیک اروپایی ممکن است نیاز به یکپارچه‌سازی با یک درگاه پرداخت جدید داشته باشد که از API متفاوتی استفاده می‌کند.
• بهبود روحیه توسعه‌دهندگان: کار با کدهای تمیز و با ساختار خوب برای توسعه‌دهندگان لذت‌بخش‌تر و سازنده‌تر است. ریفکتورینگ می‌تواند روحیه را تقویت کرده و استعدادها را جذب کند.

شناسایی کاندیداهای ریفکتورینگ

همه کدهای لگسی نیاز به ریفکتورینگ ندارند. مهم است که تلاش‌های ریفکتورینگ را بر اساس عوامل زیر اولویت‌بندی کنید:

• دفعات تغییر: کدی که به طور مکرر اصلاح می‌شود، کاندیدای اصلی برای ریفکتورینگ است، زیرا بهبود در قابلیت نگهداری تأثیر قابل توجهی بر بهره‌وری توسعه خواهد داشت.
• پیچیدگی: کدی که پیچیده و دشوار برای درک است، احتمال بیشتری برای داشتن باگ دارد و اصلاح ایمن آن سخت‌تر است.
• تأثیر باگ‌ها: کدی که برای عملیات کسب‌وکار حیاتی است یا خطر بالایی برای ایجاد خطاهای پرهزینه دارد، باید برای ریفکتورینگ در اولویت قرار گیرد.
• گلوگاه‌های عملکرد: کدی که به عنوان گلوگاه عملکرد شناسایی شده است باید برای بهبود عملکرد ریفکتور شود.
• بوهای کد (Code Smells): مراقب بوهای رایج کد مانند متدهای طولانی، کلاس‌های بزرگ، کدهای تکراری و حسادت به ویژگی (feature envy) باشید. اینها نشانگر مناطقی هستند که می‌توانند از ریفکتورینگ بهره‌مند شوند.

مثال: یک شرکت لجستیک جهانی را با یک سیستم لگسی برای مدیریت محموله‌ها تصور کنید. ماژول مسئول محاسبه هزینه‌های حمل‌ونقل به دلیل تغییر مقررات و قیمت سوخت به طور مکرر به‌روزرسانی می‌شود. این ماژول یک کاندیدای اصلی برای ریفکتورینگ است.

تکنیک‌های ریفکتورینگ

تکنیک‌های ریفکتورینگ متعددی وجود دارد که هر کدام برای رسیدگی به بوهای کد خاص یا بهبود جنبه‌های خاصی از کد طراحی شده‌اند. در اینجا برخی از تکنیک‌های رایج آورده شده است:

ترکیب متدها (Composing Methods)

این تکنیک‌ها بر شکستن متدهای بزرگ و پیچیده به متدهای کوچک‌تر و قابل مدیریت‌تر تمرکز دارند. این کار خوانایی را بهبود می‌بخشد، تکرار را کاهش می‌دهد و تست کد را آسان‌تر می‌کند.

• استخراج متد (Extract Method): این شامل شناسایی یک بلوک کد است که یک کار خاص را انجام می‌دهد و انتقال آن به یک متد جدید است.
• درون‌خطی کردن متد (Inline Method): این شامل جایگزینی یک فراخوانی متد با بدنه آن متد است. از این تکنیک زمانی استفاده کنید که نام متد به اندازه بدنه آن واضح باشد، یا زمانی که می‌خواهید از استخراج متد استفاده کنید اما متد موجود بیش از حد کوتاه است.
• جایگزینی متغیر موقت با پرس‌وجو (Replace Temp with Query): این شامل جایگزینی یک متغیر موقت با یک فراخوانی متد است که مقدار متغیر را در صورت تقاضا محاسبه می‌کند.
• معرفی متغیر توضیحی (Introduce Explaining Variable): از این تکنیک برای اختصاص نتیجه یک عبارت به یک متغیر با نام توصیفی استفاده کنید تا هدف آن را روشن سازید.

انتقال ویژگی‌ها بین اشیاء (Moving Features Between Objects)

این تکنیک‌ها بر بهبود طراحی کلاس‌ها و اشیاء با انتقال مسئولیت‌ها به جایی که به آن تعلق دارند، تمرکز می‌کنند.

• انتقال متد (Move Method): این شامل انتقال یک متد از یک کلاس به کلاس دیگری است که منطقاً به آنجا تعلق دارد.
• انتقال فیلد (Move Field): این شامل انتقال یک فیلد از یک کلاس به کلاس دیگری است که منطقاً به آنجا تعلق دارد.
• استخراج کلاس (Extract Class): این شامل ایجاد یک کلاس جدید از مجموعه‌ای منسجم از مسئولیت‌ها است که از یک کلاس موجود استخراج شده‌اند.
• درون‌خطی کردن کلاس (Inline Class): از این تکنیک برای ادغام یک کلاس در کلاس دیگر استفاده کنید، زمانی که دیگر کار کافی برای توجیه وجودش انجام نمی‌دهد.
• پنهان کردن نماینده (Hide Delegate): این شامل ایجاد متدهایی در سرور برای پنهان کردن منطق نمایندگی از کلاینت است و باعث کاهش وابستگی بین کلاینت و نماینده می‌شود.
• حذف واسطه (Remove Middle Man): اگر یک کلاس تقریباً تمام کار خود را به دیگران واگذار می‌کند، این تکنیک به حذف واسطه کمک می‌کند.
• معرفی متد خارجی (Introduce Foreign Method): یک متد به کلاس کلاینت اضافه می‌کند تا به کلاینت خدماتی ارائه دهد که واقعاً از یک کلاس سرور مورد نیاز است، اما به دلیل عدم دسترسی یا تغییرات برنامه‌ریزی‌شده در کلاس سرور، نمی‌توان آن را اصلاح کرد.
• معرفی الحاقیه محلی (Introduce Local Extension): یک کلاس جدید ایجاد می‌کند که حاوی متدهای جدید است. زمانی مفید است که شما کنترل منبع کلاس را ندارید و نمی‌توانید رفتار را مستقیماً به آن اضافه کنید.

سازماندهی داده‌ها (Organizing Data)

این تکنیک‌ها بر بهبود نحوه ذخیره و دسترسی به داده‌ها تمرکز دارند و درک و اصلاح آن را آسان‌تر می‌کنند.

• جایگزینی مقدار داده با شیء (Replace Data Value with Object): این شامل جایگزینی یک مقدار داده ساده با یک شیء است که داده‌ها و رفتارهای مرتبط را کپسوله می‌کند.
• تبدیل مقدار به مرجع (Change Value to Reference): این شامل تبدیل یک شیء مقدار (value object) به یک شیء مرجع (reference object) است، زمانی که چندین شیء مقدار یکسانی را به اشتراک می‌گذارند.
• تبدیل ارتباط یک‌طرفه به دوطرفه (Change Unidirectional Association to Bidirectional): یک پیوند دوطرفه بین دو کلاس ایجاد می‌کند در حالی که فقط یک پیوند یک‌طرفه وجود دارد.
• تبدیل ارتباط دوطرفه به یک‌طرفه (Change Bidirectional Association to Unidirectional): با یک‌طرفه کردن یک رابطه دوطرفه، ارتباطات را ساده می‌کند.
• جایگزینی عدد جادویی با ثابت نمادین (Replace Magic Number with Symbolic Constant): این شامل جایگزینی مقادیر لیترال با ثابت‌های نام‌گذاری شده است، که درک و نگهداری کد را آسان‌تر می‌کند.
• کپسوله‌سازی فیلد (Encapsulate Field): یک متد getter و setter برای دسترسی به فیلد فراهم می‌کند.
• کپسوله‌سازی مجموعه (Encapsulate Collection): تضمین می‌کند که تمام تغییرات در مجموعه از طریق متدهای با دقت کنترل شده در کلاس مالک انجام می‌شود.
• جایگزینی رکورد با کلاس داده (Replace Record with Data Class): یک کلاس جدید با فیلدهایی مطابق با ساختار رکورد و متدهای دسترسی ایجاد می‌کند.
• جایگزینی کد نوع با کلاس (Replace Type Code with Class): یک کلاس جدید ایجاد می‌کند زمانی که کد نوع دارای مجموعه محدودی از مقادیر ممکن و شناخته شده است.
• جایگزینی کد نوع با زیرکلاس‌ها (Replace Type Code with Subclasses): برای زمانی که مقدار کد نوع بر رفتار کلاس تأثیر می‌گذارد.
• جایگزینی کد نوع با وضعیت/استراتژی (Replace Type Code with State/Strategy): برای زمانی که مقدار کد نوع بر رفتار کلاس تأثیر می‌گذارد، اما استفاده از زیرکلاس مناسب نیست.
• جایگزینی زیرکلاس با فیلدها (Replace Subclass with Fields): یک زیرکلاس را حذف کرده و فیلدهایی را به سوپرکلاس اضافه می‌کند که ویژگی‌های متمایز زیرکلاس را نشان می‌دهند.

ساده‌سازی عبارات شرطی (Simplifying Conditional Expressions)

منطق شرطی می‌تواند به سرعت پیچیده شود. این تکنیک‌ها با هدف شفاف‌سازی و ساده‌سازی انجام می‌شوند.

• تجزیه شرط (Decompose Conditional): این شامل شکستن یک عبارت شرطی پیچیده به قطعات کوچک‌تر و قابل مدیریت‌تر است.
• ادغام عبارت شرطی (Consolidate Conditional Expression): این شامل ترکیب چندین عبارت شرطی در یک عبارت واحد و مختصرتر است.
• ادغام قطعات شرطی تکراری (Consolidate Duplicate Conditional Fragments): این شامل انتقال کدی است که در چندین شاخه از یک عبارت شرطی تکرار شده است به خارج از شرط.
• حذف پرچم کنترلی (Remove Control Flag): متغیرهای بولین که برای کنترل جریان منطق استفاده می‌شوند را حذف کنید.
• جایگزینی شرط تودرتو با گارد کلازها (Replace Nested Conditional with Guard Clauses): با قرار دادن تمام موارد خاص در بالا و توقف پردازش در صورت صحت هر یک از آنها، کد را خواناتر می‌کند.
• جایگزینی شرط با پلی‌مورفیسم (Replace Conditional with Polymorphism): این شامل جایگزینی منطق شرطی با پلی‌مورفیسم است، که به اشیاء مختلف اجازه می‌دهد موارد مختلف را مدیریت کنند.
• معرفی شیء تهی (Introduce Null Object): به جای بررسی مقدار تهی (null)، یک شیء پیش‌فرض ایجاد کنید که رفتار پیش‌فرض را ارائه می‌دهد.
• معرفی ادعا (Introduce Assertion): با ایجاد یک تست که انتظارات را بررسی می‌کند، آنها را به صراحت مستند کنید.

ساده‌سازی فراخوانی متدها (Simplifying Method Calls)

• تغییر نام متد (Rename Method): این کار به نظر بدیهی می‌آید، اما در شفاف‌سازی کد فوق‌العاده مفید است.
• افزودن پارامتر (Add Parameter): افزودن اطلاعات به امضای متد به آن اجازه می‌دهد انعطاف‌پذیرتر و قابل استفاده مجدد باشد.
• حذف پارامتر (Remove Parameter): اگر از یک پارامتر استفاده نمی‌شود، آن را حذف کنید تا رابط کاربری ساده‌تر شود.
• جداسازی پرس‌وجو از اصلاح‌کننده (Separate Query from Modifier): اگر یک متد هم مقدار را تغییر می‌دهد و هم بازمی‌گرداند، آن را به دو متد مجزا تقسیم کنید.
• پارامتری‌سازی متد (Parameterize Method): از این تکنیک برای ادغام متدهای مشابه در یک متد واحد با یک پارامتر که رفتار را تغییر می‌دهد، استفاده کنید.
• جایگزینی پارامتر با متدهای صریح (Replace Parameter with Explicit Methods): برعکس پارامتری‌سازی عمل کنید - یک متد واحد را به چندین متد تقسیم کنید که هر کدام نمایانگر یک مقدار خاص از پارامتر هستند.
• حفظ شیء کامل (Preserve Whole Object): به جای ارسال چند آیتم داده خاص به یک متد، کل شیء را ارسال کنید تا متد به تمام داده‌های آن دسترسی داشته باشد.
• جایگزینی پارامتر با متد (Replace Parameter with Method): اگر یک متد همیشه با همان مقدار مشتق شده از یک فیلد فراخوانی می‌شود، در نظر بگیرید که مقدار پارامتر را درون متد استخراج کنید.
• معرفی شیء پارامتر (Introduce Parameter Object): چندین پارامتر را که به طور طبیعی به هم تعلق دارند، در یک شیء گروه‌بندی کنید.
• حذف متد تنظیم‌کننده (Remove Setting Method): از سترها (setters) اجتناب کنید اگر یک فیلد فقط باید مقداردهی اولیه شود و پس از ساخت، اصلاح نشود.
• پنهان کردن متد (Hide Method): قابلیت مشاهده یک متد را کاهش دهید اگر فقط در یک کلاس استفاده می‌شود.
• جایگزینی سازنده با متد کارخانه (Replace Constructor with Factory Method): یک جایگزین توصیفی‌تر برای سازنده‌ها.
• جایگزینی استثنا با تست (Replace Exception with Test): اگر از استثناها به عنوان کنترل جریان استفاده می‌شود، آنها را با منطق شرطی جایگزین کنید تا عملکرد بهبود یابد.

کار با تعمیم (Dealing with Generalization)

• بالا بردن فیلد (Pull Up Field): یک فیلد را از یک زیرکلاس به سوپرکلاس آن منتقل کنید.
• بالا بردن متد (Pull Up Method): یک متد را از یک زیرکلاس به سوپرکلاس آن منتقل کنید.
• بالا بردن بدنه سازنده (Pull Up Constructor Body): بدنه یک سازنده را از یک زیرکلاس به سوپرکلاس آن منتقل کنید.
• پایین بردن متد (Push Down Method): یک متد را از یک سوپرکلاس به زیرکلاس‌های آن منتقل کنید.
• پایین بردن فیلد (Push Down Field): یک فیلد را از یک سوپرکلاس به زیرکلاس‌های آن منتقل کنید.
• استخراج رابط (Extract Interface): یک رابط از متدهای عمومی یک کلاس ایجاد می‌کند.
• استخراج سوپرکلاس (Extract Superclass): عملکرد مشترک دو کلاس را به یک سوپرکلاس جدید منتقل کنید.
• ادغام سلسله‌مراتب (Collapse Hierarchy): یک سوپرکلاس و زیرکلاس را در یک کلاس واحد ترکیب کنید.
• تشکیل متد الگو (Form Template Method): یک متد الگو در یک سوپرکلاس ایجاد کنید که مراحل یک الگوریتم را تعریف می‌کند و به زیرکلاس‌ها اجازه می‌دهد مراحل خاصی را بازنویسی کنند.
• جایگزینی وراثت با نمایندگی (Replace Inheritance with Delegation): به جای به ارث بردن عملکرد، یک فیلد در کلاس ایجاد کنید که به آن عملکرد ارجاع می‌دهد.
• جایگزینی نمایندگی با وراثت (Replace Delegation with Inheritance): زمانی که نمایندگی بیش از حد پیچیده است، به وراثت تغییر دهید.

اینها تنها چند نمونه از تکنیک‌های ریفکتورینگ متعدد موجود هستند. انتخاب اینکه از کدام تکنیک استفاده شود به بوی کد خاص و نتیجه مطلوب بستگی دارد.

مثال: یک متد بزرگ در یک برنامه جاوا که توسط یک بانک جهانی استفاده می‌شود، نرخ‌های بهره را محاسبه می‌کند. اعمال استخراج متد (Extract Method) برای ایجاد متدهای کوچک‌تر و متمرکزتر، خوانایی را بهبود می‌بخشد و به‌روزرسانی منطق محاسبه نرخ بهره را بدون تأثیر بر سایر بخش‌های متد آسان‌تر می‌کند.

فرآیند ریفکتورینگ

ریفکتورینگ باید به صورت سیستماتیک انجام شود تا ریسک به حداقل برسد و شانس موفقیت به حداکثر برسد. در اینجا یک فرآیند پیشنهادی ارائه شده است:

1. شناسایی کاندیداهای ریفکتورینگ: از معیارهای ذکر شده قبلی برای شناسایی مناطقی از کد که بیشترین سود را از ریفکتورینگ می‌برند، استفاده کنید.
2. ایجاد تست‌ها: قبل از ایجاد هرگونه تغییر، تست‌های خودکار بنویسید تا رفتار موجود کد را تأیید کنید. این برای اطمینان از اینکه ریفکتورینگ رگرسیون ایجاد نمی‌کند، حیاتی است. ابزارهایی مانند JUnit (جاوا)، pytest (پایتون) یا Jest (جاوا اسکریپت) می‌توانند برای نوشتن تست‌های واحد استفاده شوند.
3. ریفکتورینگ تدریجی: تغییرات کوچک و تدریجی ایجاد کنید و پس از هر تغییر تست‌ها را اجرا کنید. این کار شناسایی و رفع هرگونه خطایی که معرفی می‌شود را آسان‌تر می‌کند.
4. کامیت مکرر: تغییرات خود را به طور مکرر در کنترل نسخه کامیت کنید. این به شما امکان می‌دهد در صورت بروز مشکل به راحتی به نسخه قبلی بازگردید.
5. بررسی کد: کد خود را توسط یک توسعه‌دهنده دیگر بررسی کنید. این می‌تواند به شناسایی مشکلات بالقوه کمک کرده و اطمینان حاصل کند که ریفکتورینگ به درستی انجام شده است.
6. نظارت بر عملکرد: پس از ریفکتورینگ، عملکرد سیستم را نظارت کنید تا اطمینان حاصل شود که تغییرات هیچ‌گونه رگرسیون عملکردی ایجاد نکرده‌اند.

مثال: تیمی که در حال ریفکتورینگ یک ماژول پایتون در یک پلتفرم تجارت الکترونیک جهانی است، از `pytest` برای ایجاد تست‌های واحد برای عملکرد موجود استفاده می‌کند. سپس آنها ریفکتورینگ استخراج کلاس (Extract Class) را برای جداسازی مسئولیت‌ها و بهبود ساختار ماژول اعمال می‌کنند. پس از هر تغییر کوچک، آنها تست‌ها را اجرا می‌کنند تا اطمینان حاصل کنند که عملکرد بدون تغییر باقی مانده است.

استراتژی‌هایی برای افزودن تست به کدهای لگسی

همانطور که مایکل فدرز به درستی بیان کرد، کد لگسی کدی بدون تست است. افزودن تست به پایگاه کدهای موجود می‌تواند یک کار عظیم به نظر برسد، اما برای ریفکتورینگ ایمن ضروری است. در اینجا چندین استراتژی برای انجام این کار آورده شده است:

تست‌های مشخصه‌یابی (Characterization Tests) (یا Golden Master Tests)

هنگامی که با کدی سر و کار دارید که درک آن دشوار است، تست‌های مشخصه‌یابی می‌توانند به شما کمک کنند تا رفتار موجود آن را قبل از شروع تغییرات ثبت کنید. ایده این است که تست‌هایی بنویسید که خروجی فعلی کد را برای مجموعه معینی از ورودی‌ها تأیید می‌کنند. این تست‌ها لزوماً صحت را تأیید نمی‌کنند؛ آنها به سادگی آنچه را که کد *در حال حاضر* انجام می‌دهد، مستند می‌کنند.

مراحل:

1. یک واحد کد را که می‌خواهید مشخصه‌یابی کنید (مثلاً یک تابع یا متد) شناسایی کنید.
2. مجموعه‌ای از مقادیر ورودی ایجاد کنید که طیفی از سناریوهای رایج و موارد خاص (edge-case) را نشان می‌دهند.
3. کد را با آن ورودی‌ها اجرا کرده و خروجی‌های حاصل را ثبت کنید.
4. تست‌هایی بنویسید که تأیید کنند کد دقیقاً آن خروجی‌ها را برای آن ورودی‌ها تولید می‌کند.

احتیاط: اگر منطق زیربنایی پیچیده یا وابسته به داده باشد، تست‌های مشخصه‌یابی می‌توانند شکننده باشند. آماده باشید تا در صورت نیاز به تغییر رفتار کد، آنها را به‌روزرسانی کنید.

متد جوانه (Sprout Method) و کلاس جوانه (Sprout Class)

این تکنیک‌ها که توسط مایکل فدرز نیز توصیف شده‌اند، با هدف افزودن قابلیت‌های جدید به یک سیستم لگسی و در عین حال به حداقل رساندن خطر شکستن کدهای موجود انجام می‌شوند.

متد جوانه: هنگامی که نیاز به افزودن یک ویژگی جدید دارید که مستلزم اصلاح یک متد موجود است، یک متد جدید ایجاد کنید که حاوی منطق جدید باشد. سپس، این متد جدید را از متد موجود فراخوانی کنید. این به شما امکان می‌دهد کد جدید را جدا کرده و آن را به طور مستقل تست کنید.

کلاس جوانه: مشابه متد جوانه، اما برای کلاس‌ها. یک کلاس جدید ایجاد کنید که قابلیت جدید را پیاده‌سازی می‌کند و سپس آن را در سیستم موجود ادغام کنید.

جعبه شنی (Sandboxing)

جعبه شنی شامل جداسازی کد لگسی از بقیه سیستم است و به شما امکان می‌دهد آن را در یک محیط کنترل شده تست کنید. این کار را می‌توان با ایجاد ماک‌ها (mocks) یا استاب‌ها (stubs) برای وابستگی‌ها یا با اجرای کد در یک ماشین مجازی انجام داد.

روش میکادو (The Mikado Method)

روش میکادو یک رویکرد حل مسئله بصری برای مقابله با وظایف پیچیده ریفکتورینگ است. این شامل ایجاد یک نمودار است که وابستگی‌های بین بخش‌های مختلف کد را نشان می‌دهد و سپس ریفکتورینگ کد به گونه‌ای که تأثیر آن بر سایر بخش‌های سیستم به حداقل برسد. اصل اصلی این است که تغییر را «امتحان کنید» و ببینید چه چیزی خراب می‌شود. اگر خراب شد، به آخرین وضعیت کاری بازگردید و مشکل را ثبت کنید. سپس قبل از تلاش مجدد برای تغییر اصلی، آن مشکل را برطرف کنید.

ابزارهای ریفکتورینگ

چندین ابزار می‌توانند به ریفکتورینگ کمک کنند، کارهای تکراری را خودکار کرده و در مورد بهترین شیوه‌ها راهنمایی ارائه دهند. این ابزارها اغلب در محیط‌های توسعه یکپارچه (IDE) ادغام شده‌اند:

• محیط‌های توسعه یکپارچه (IDE) (مانند IntelliJ IDEA، Eclipse، Visual Studio): IDEها ابزارهای ریفکتورینگ داخلی را ارائه می‌دهند که می‌توانند به طور خودکار کارهایی مانند تغییر نام متغیرها، استخراج متدها و انتقال کلاس‌ها را انجام دهند.
• ابزارهای تحلیل استاتیک (مانند SonarQube، Checkstyle، PMD): این ابزارها کد را برای بوهای کد، باگ‌های بالقوه و آسیب‌پذیری‌های امنیتی تجزیه و تحلیل می‌کنند. آنها می‌توانند به شناسایی مناطقی از کد که از ریفکتورینگ سود می‌برند، کمک کنند.
• ابزارهای پوشش کد (مانند JaCoCo، Cobertura): این ابزارها درصد کدی را که توسط تست‌ها پوشش داده شده است، اندازه‌گیری می‌کنند. آنها می‌توانند به شناسایی مناطقی از کد که به اندازه کافی تست نشده‌اند، کمک کنند.
• مرورگرهای ریفکتورینگ (مانند Smalltalk Refactoring Browser): ابزارهای تخصصی که در فعالیت‌های بازسازی بزرگ‌تر کمک می‌کنند.

مثال: یک تیم توسعه که روی یک برنامه #C برای یک شرکت بیمه جهانی کار می‌کند، از ابزارهای ریفکتورینگ داخلی Visual Studio برای تغییر نام خودکار متغیرها و استخراج متدها استفاده می‌کند. آنها همچنین از SonarQube برای شناسایی بوهای کد و آسیب‌پذیری‌های بالقوه استفاده می‌کنند.

چالش‌ها و ریسک‌ها

ریفکتورینگ کدهای لگسی بدون چالش و ریسک نیست:

• معرفی رگرسیون‌ها: بزرگترین ریسک، معرفی باگ‌ها در طول فرآیند ریفکتورینگ است. این را می‌توان با نوشتن تست‌های جامع و ریفکتورینگ تدریجی کاهش داد.
• فقدان دانش دامنه: اگر توسعه‌دهندگان اصلی رفته باشند، درک کد و هدف آن می‌تواند دشوار باشد. این می‌تواند به تصمیمات نادرست در ریفکتورینگ منجر شود.
• وابستگی شدید (Tight Coupling): ریفکتورینگ کدهای به شدت به هم‌پیوسته دشوارتر است، زیرا تغییرات در یک بخش از کد می‌تواند عواقب ناخواسته‌ای بر سایر بخش‌های کد داشته باشد.
• محدودیت‌های زمانی: ریفکتورینگ می‌تواند زمان‌بر باشد و توجیه سرمایه‌گذاری برای ذینفعانی که بر ارائه ویژگی‌های جدید متمرکز هستند، دشوار است.
• مقاومت در برابر تغییر: برخی از توسعه‌دهندگان ممکن است در برابر ریفکتورینگ مقاومت کنند، به خصوص اگر با تکنیک‌های مربوطه آشنا نباشند.

بهترین شیوه‌ها

برای کاهش چالش‌ها و ریسک‌های مرتبط با ریفکتورینگ کدهای لگسی، این بهترین شیوه‌ها را دنبال کنید:

• کسب موافقت: اطمینان حاصل کنید که ذینفعان مزایای ریفکتورینگ را درک کرده و مایل به سرمایه‌گذاری زمان و منابع مورد نیاز هستند.
• کوچک شروع کنید: با ریفکتورینگ قطعات کوچک و جدا شده از کد شروع کنید. این به ایجاد اعتماد به نفس و نشان دادن ارزش ریفکتورینگ کمک می‌کند.
• ریفکتورینگ تدریجی: تغییرات کوچک و تدریجی ایجاد کرده و به طور مکرر تست کنید. این کار شناسایی و رفع هرگونه خطایی که معرفی می‌شود را آسان‌تر می‌کند.
• خودکارسازی تست‌ها: تست‌های خودکار جامع بنویسید تا رفتار کد را قبل و بعد از ریفکتورینگ تأیید کنید.
• استفاده از ابزارهای ریفکتورینگ: از ابزارهای ریفکتورینگ موجود در IDE خود یا ابزارهای دیگر برای خودکارسازی کارهای تکراری و ارائه راهنمایی در مورد بهترین شیوه‌ها استفاده کنید.
• مستندسازی تغییرات: تغییراتی را که در طول ریفکتورینگ ایجاد می‌کنید، مستند کنید. این به سایر توسعه‌دهندگان کمک می‌کند تا کد را درک کرده و از معرفی رگرسیون‌ها در آینده جلوگیری کنند.
• ریفکتورینگ مستمر: ریفکتورینگ را به بخشی مستمر از فرآیند توسعه تبدیل کنید، نه یک رویداد یک‌باره. این به تمیز و قابل نگهداری نگه داشتن پایگاه کد کمک می‌کند.

نتیجه‌گیری

ریفکتورینگ کدهای لگسی یک تلاش چالش‌برانگیز اما ارزشمند است. با دنبال کردن استراتژی‌ها و بهترین شیوه‌های ذکر شده در این راهنما، می‌توانید این هیولا را رام کرده و سیستم‌های لگسی خود را به دارایی‌های قابل نگهداری، قابل اعتماد و با عملکرد بالا تبدیل کنید. به یاد داشته باشید که به صورت سیستماتیک به ریفکتورینگ نزدیک شوید، به طور مکرر تست کنید و به طور موثر با تیم خود ارتباط برقرار کنید. با برنامه‌ریزی و اجرای دقیق، می‌توانید پتانسیل پنهان در کدهای لگسی خود را آزاد کرده و راه را برای نوآوری‌های آینده هموار کنید.